The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
In recent years, use of large-scale networks that exchange, process, and store large amounts of data at high speed is proliferating. Consequently, demand for reliable data storage systems is increasing. Particularly, engineers strive to design error detecting/correcting systems that can write data on disk drives in a manner that will enable detecting and correcting errors when the data is read back.
For example, an encoder may encode the data using one or more error-correcting codes such as Reed-Solomon codes before writing the data on a disk drive. When the data is read back, a decoder may decode the data and detect and/or correct errors. The ability of systems to detect and/or correct errors depends on types of error and error-correcting capabilities of codes used to encode the data.
Data is typically read from disks in sectors or blocks. Data read from a disk is considered reliable if the data read is the same as the data that was written on the disk. To enable error-detection when data is read from a disk, a cyclic redundancy check (CRC) is performed on the data before the data is written on the disk. CRC for a block is typically generated as follows. A polynomial is used to represent the data in the block. The polynomial is divided by a predetermined binary polynomial. A remainder resulting from the division is called a checksum of the data. The checksum is appended to the block before the block is written and stored in the disk.
When the block is read from the disk, the same division is performed, and the remainder of the division is compared to the checksum in the block. The data in the block is considered reliable if the remainder matches the checksum. Typically, a logical block address (LBA) is associated with each block. The LBA indicates an address or a location where the block is stored in the disk. In addition to protecting the data in the block, the CRC may protect the LBA information of the block.
CRC, however, may not detect errors when data read differs from data written due to an error and yet generates identical remainders in read and write operations. An error-correcting code (ECC), on the other hand, enables not only detection but also correction of some errors that may be detected in the block when the block is read from the disk. Typically, an error-correcting code such as a Reed-Solomon code is used to calculate parity for the block. The parity is appended to the block to generate a codeword, and the codeword is stored in the disk.
When the block is read from the disk, a calculation is performed to determine if the block read is a valid codeword. The data in the block is considered error-free if the block read is a valid codeword. If errors are detected, a decoder may try to correct the error. Correct data can be reconstructed if the number of errors is less than or equal to an error-correcting capability of the code used.
Referring now to FIG. 1, a data processing system 10 may include a processor 12, a hard disk drive (HDD) 14, a host adapter 16, and system memory 18. The processor 12, the host adapter 16, and system memory 18 may communicate via a system bus 20. The HDD 14 may communicate with the host adapter 16 via a standard I/O interface 24 such as ATA, SATA, etc.
The host adapter 16 may read the data from the disk drive 14 into system memory 18. The processor 12 may read the data from system memory 18 and process the data in system memory 18. The host adapter 16 may read the processed data from system memory 18 and store the processed data in the HDD 14.
Referring now to FIG. 2, the HDD 14 may include a hard disk assembly (HDA) 14-1 and a HDD printed circuit board (PCB) 14-2. The HDA 14-1 may include one or more circular platters 15 having a magnetic medium that is used to store data magnetically. Data is stored in binary form as a magnetic field of either positive or negative polarity. The platters 15 are arranged in a stack, and the stack is rotated by a spindle motor 17. At least one read/write head (hereinafter “head”) 19 reads data from and writes data on the platters 15.
Each head 19 may include a write element such as an inductor that generates a magnetic field and a read element such as a magneto-resistive (MR) element that senses the magnetic field on the platters 15. The head 19 may be mounted at a distal end of an actuator arm 22. An actuator such as a voice coil motor (VCM) 23 may move the actuator arm 22 relative to the platters 15.
The HDA 14-1 may include a preamplifier device 26 that amplifies signals received from and sent to the head 19. When writing data, the preamplifier device 26 may generate a write current that flows through the write element of the head 19. The write current may be switched to produce a positive or negative magnetic field on the platters 15.
When reading data, the magnetic fields stored on the platters 15 induce low-level analog signals in the read element of the head 19. The preamplifier device 26 amplifies the low-level analog signals and outputs amplified analog signals to a read/write channel (hereinafter “read-channel”) module 28.
The HDD PCB 14-2 may include the read-channel module 28, a hard disk controller (HDC) module 30, a processor 32, a spindle/VCM driver module 34, a buffer 36, nonvolatile memory 38, and the I/O interface 24. During write operations, the read-channel module 28 may encode the data to increase reliability. The read-channel module 28 may use error-correction coding (ECC), run length limited (RLL) coding, Reed-Solomon encoding, etc., to encode the data. The read-channel module 28 may output the encoded data to the preamplifier device 26. During read operations, the read-channel module 28 may receive analog signals from the preamplifier device 26. The read-channel module 28 may convert the analog signals into digital signals, which may be filtered and decoded to recover the original data.
The HDC module 30 controls operation of the HDD 14. For example, the HDC module 30 may generate commands that control the speed of the spindle motor 17 and the movement of the actuator arm 22. The spindle/VCM driver module 34 may implement the commands and generate control signals that control the speed of the spindle motor 17 and the positioning of the actuator arm 22.
The HDC module 30 may communicate with an external device such as the host adapter 16 via the I/O interface 24. The HDC module 30 may receive data to be stored in the HDD 14 from the external device and may transmit data stored in the HDD 14 to the external device. The HDC module 30 may use the buffer 36 to temporarily store data and commands during read/write operations.
The processor 32 may process data, including encoding, decoding, filtering, and/or formatting. Additionally, the processor 32 may process servo or positioning information to position the heads 19 relative to the platters 15 during read/write operations. Servo, which is stored on the platters 15, ensures that data is written to and read from correct locations on the platters 15. In some implementations, a self-servo write (SSW) module 42 may write servo on the platters 15 using the heads 19 prior to storing data on the HDD 14.
During read/write operations, data in HDD 14 may flow through read/write data-paths and may be communicated from one module to another. For example, during a write operation, data may flow through a write data-path. Specifically, data may be received by the I/O interface 24, stored in the buffer 36, encoded and/or formatted by the read-channel module 28, etc. before the data may be written on the platters 15. Similarly, during a read operation, data may flow through a read data-path. Specifically, data read from the platters 15 may be processed by the read-channel module 28, stored in the buffer 36, etc., before the data may be transmitted to the host adapter 16 via the I/O interface 24.
Data may get corrupted when the data is communicated from one module to another in read/write data-paths. For example, data may get corrupted due to noise, physical defects in platters 15, defects in one or more modules, etc. Corrupted data may not be reliable if errors due to corruption are irrecoverable.